mysql select user auth plugins

select user, plugin from mysql.user;

+------------------+-----------------------+
| user             | plugin                |
+------------------+-----------------------+
| root             | mysql_native_password |
| mysql.infoschema | caching_sha2_password |
| mysql.session    | caching_sha2_password |
| mysql.sys        | caching_sha2_password |
| root             | mysql_native_password |
+------------------+-----------------------+

Downgrade composer to use v1

composer self-update --1

mysql 8 w php <8

php can’t connect using the default auth (caching_sha2_password) so it needs to be set to mysql_native_password

In mysql conf file (depends on distro), add/uncomment:

[mysqld]
default_authentication_plugin= mysql_native_password

This may be in the root conf, or a specific file included by the !includedir directive

mysql 8 w php7 and laravel 5.5.19 (<…41)

Need to add the following to the mysql config within the database.php config file:

mode => [
'ONLY_FULL_GROUP_BY',
'STRICT_TRANS_TABLES',
'NO_ZERO_IN_DATE',
'NO_ZERO_DATE',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_ENGINE_SUBSTITUTION',
]

In my exerience with docker, this didn’t work and first load of the site didn’t work (connection refused). Then removing, save/reload, re-add, save/reload worked

Laravel 5.5 With Docker

• Setting Up Laravel with Docker Compose (Docker Docs)
• Docker Workshop (Intro Tutorial)
• Laravel Docker Examples
• Red’s commit to Para2 as similar reference

Helpful Docker Shits

• docker-compose.yaml file - shorthand file to compile long cli args into friendlier format that can be reused for consistency. guide
• .dockerignore file - similar to git ignore; tells docker to ignore files when doing things. I guess I should get a better understanding of what “things” are. “The Build Context.” “This helps avoid sending unwanted files and directories to the builder, improving build speed, especially when using a remote builder.”

General Docker Info

• There are two types of Volumes that come into play: named volumes and bind mounts.
  • Named volumes can persist data across instances (like saved mysql data)
  • Bind mounts essentially link file systems across host and container (such as binding edits to host files to update container files)
  • In both cases, a mapping is made between the volume and the target (volume name to mysql data mapping; host path to container path)
    • Named
      docker run -d <app> -v <volume_name>:/var/lib/mysql [...]
    • Bind Mount
      docker run [...] --mount type=bind,src="$(pwd)",target=/src [...]

General Idea

Create docker images for each isolated component of the app service (separation of concerns, scalability). Via docker-compose file, these will be connected via a network. Then through configs, have them talk to each other in the necessary ways.

• PHP-FPM container: runs the laravel app. Should also contain other libs necessary to tun the app
• Nginx container: listens to connections to the container on web ports. Shows files in public directory, and proxies all other connections to the PHP-FPM container
• Mysql container: runs the database. PHP-FPM container connects to this via the laravel app env configs. Again, available on network due to compose file and ip is aliased via name of service in compose file.

Further Reading

• Docker Manuals
• Docker Compose File Reference
• Dockerfile Reference
• Why you shouldn’t use ENV variables for secret data
• The twelve-factor app
• Getting Started with Docker (Dockercon 2022 or something)
• PHP-fpm health check

Docker Commands

Run the compose/build docker compose up --build -d
docker ps
docker exec -it <container_id> bash

END

After spending two days in docker surrounding a legacy application, figuring out wonky details that related to complex docker stuff and complex container/configuration stuff became less of a priority. Up and running with minimum necessary to install, run, edit and push changes for dev environment, knowing this has a dedicated prod environment.